Synchronization operations involving entity identifiers

ABSTRACT

Mechanisms are provided for identity mapping in synchronization systems. For example, entities can be mapped across various entity stores, such that an entity in one store can be identified with an entity in another store even if such entities are of different types. When entities are being synchronized across various entity stores, new or updated entity identities (and associated metadata) can be supplied to these stores as part of the same operation as that used for supplying changes during synchronization: entities can be merged and associated identity information and metadata can be changed accordingly; entities can be resurrected and new identity information can be created; metadata can be utilized even though entities are deleted, and so on.

COPYRIGHT NOTICE AND PERMISSION

A portion of the disclosure of this patent document may contain materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever. The following notice shall apply to this document:Copyright© 2004-2006, Microsoft Corp.

FIELD OF TECHNOLOGY

The present subject matter relates to the field of computing, and moreparticularly, to file and/or storage systems, although such systemscorrespond to merely an exemplary and non-limiting field of thepresently disclosed subject matter.

BACKGROUND

Storage and management systems such as WinFS (Microsoft Windows® FutureStorage or Microsoft Windows® File System), for example, allow differentkinds of data to be identified by metadata and use this metadata to setup relationships among data, thereby giving a semantic structure to it.These relationships can then be used by a relational database to enablesearching and dynamic aggregation of such data, allowing it to bepresented in a variety of ways. In one setup, WinFS can include arelational database engine, derived from the Microsoft® SQL Serverdatabase platform, to facilitate such manipulation of data.

WinFS can maintain various entity stores. Such stores may have to besynchronized periodically. Broadly speaking, synchronization is theprocess of maintaining two or more data stores to be identical undersome series of changes, both local and remote. This involves, at certainpoints in time, using synchronization operations, which move changesmade on one store (since the last synchronization operation with anotherstore) to the another store. These changes may conflict, sosynchronization solutions often include conflict detection andresolution mechanisms.

This process of moving changes back and forth raises a requirement foran identity mapping mechanism. Given changes to entities from one storeit may be necessary for synchronization to determine the correspondingentities in the other store to which those changes should be applied.Thus, one problem is the identification of corresponding entities acrossvarious entity stores. Another problem is the maintenance of entityidentifications when numerous operations have occurred.

In short, mechanisms are needed, whether systems, methods, computerreadable media, and so on, that addresses in an efficient manner theseproblems.

SUMMARY

To address these aforementioned problems, mechanisms are provided foridentity mapping in synchronization systems. Entities can be mappedacross various entity stores, such that an entity in one store can beidentified with an entity in another store even if such entities are ofdifferent types. Moreover, when entities are being synchronized acrossvarious entity stores, new or updated entity identities, along withmetadata, can be supplied to these stores as part of the same operationas that used for supplying changes during synchronization.

In one aspect of the presently disclosed subject matter, entities can bemerged and associated identity information and metadata can be changedaccordingly. In another aspect, entities can be resurrected and newidentity information can be created. In yet another aspect, metadata canbe utilized even though entities are deleted.

Thus, it should be noted that this Summary is provided to introduce aselection of concepts in a simplified form that are further describedbelow in the Detailed Description. This Summary is not intended toidentify key features or essential features of the claimed subjectmatter, nor is it intended to be used as an aid in determining the scopeof the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing Summary, as well as the following Detailed Description, isbetter understood when read in conjunction with the appended drawings.In order to illustrate the present disclosure, various aspects of thedisclosure are shown. However, the disclosure is not limited to thespecific aspects discussed. The following figures are included:

FIG. 1 illustrates a block diagram illustrating an exemplary typehierarchy;

FIG. 2 illustrates a block diagram illustrating an example use ofpredefined types in defining a new type;

FIG. 3 illustrates a block diagram illustrating an exemplary relationstored as a reference to a particular row in the table of an item;

FIG. 4 illustrates a synchronization mechanism which includesidentification information for entities in various stores;

FIG. 5 illustrates the potential disparity between identificationinformation hierarchy and entity hierarchy;

FIG. 6 illustrates that identifiers may be assigned to individualcomponents of a given entity;

FIG. 7 illustrates that a merger of entities may result in assignment ofprimary and secondary identifiers;

FIG. 8 illustrates the fact that a secondary (per entity) storage may beprovided with each entity;

FIG. 9 illustrates in block diagram form aspects discussed with respectto the previous figures;

FIG. 10 illustrates a block diagram representing an exemplary computingdevice suitable for use in conjunction with a storage system employingidentification mapping; and

FIG. 11 illustrates an exemplary networked computing environment inwhich many computerized processes may be implemented to perform theaforementioned identification mapping in various devices across anetwork.

DETAILED DESCRIPTION

Certain specific details are set forth in this description andaccompanying figures to provide a thorough understanding of variousaspects of the presently disclosed subject matter. However, certainwell-known details often associated with computing and softwaretechnology are not set forth in this disclosure in order to avoidunnecessarily obscuring these various aspects. Further, those ofordinary skill in the relevant art will understand that they canpractice other aspects of the presently disclosed subject matter withoutone or more of the details described below. Finally, while variousmethods are described with reference to steps and sequences in thisdescription, the description as such is for providing a clearimplementation of the aforementioned aspects, and the steps andsequences of steps should not be taken as required to practice thissubject matter.

Overview of Microsoft Windows® File System (WinFS®)

Although the concepts, ideas and features described herein are describedin an exemplary fashion with respect to how they are implemented in afile system called Microsoft Windows® Future Storage or MicrosoftWindows® File System (WinFS) and the Microsoft Windows Vista® operatingsystem, implementations in and applicability to other operating and filesystems are contemplated, entirely possible and apparent to thoseskilled in the art based on the exemplary descriptions provided herein.Provided in this section is an overview of WinFS, drawn largely fromsources such as http://www.msdn.com and other derivative sources thereofsuch as http://www.wikipedia.org, which includes description of the datastorage, data model, type system, relationships, rules, access control,data retrieval, search and data sharing aspects of WinFS.

WinFS is a data storage and management system based on relationaldatabases, developed by Microsoft Corp. (headquartered in Redmond,Wash.) for use as an advanced storage subsystem for the MicrosoftWindows® operating system. Implemented on top of the NT File System(NTFS), one of the file systems for the Microsoft Windows NT® operatingsystem, WinFS is a centralized data store for the Microsoft Windows®platform.

In WinFS, artificial organization using names and location is done awaywith, and a more natural organization is created than in hierarchical ordesktop search systems—namely, one using rich properties to describe thedata in files and the relation of that data with other data. By creatinga unified datastore, WinFS promotes sharing and reuse of data betweendifferent applications. One advantage over any prior art is that anyapplication, or even the file browser, can understand files created byany application. Addition of rich properties gives further meaning tothe data, such as “which persons appear in which pictures,” and “theperson an e-mail was addressed to.” But, instead of viewing the picturesand e-mails and files, WinFS recognizes picture, and e-mail to bespecific types of data, which are related to person using the relation“of some person.” So, by following the relation, a picture can be usedto aggregate e-mails from all the persons in the picture and,conversely, an e-mail can aggregate all pictures in which the addresseeappears in. WinFS extends this to understand any arbitrary types of dataand the relations that hold them together. The types and relations haveto be specified by the application that stores the data, or the user,and WinFS organizes the data accordingly.

WinFS stores data in virtual locations called stores. A WinFS store is acommon repository where every application will store their data, alongwith its metadata, relationships and information on how to interpret thedata. In this way, WinFS does away with the folder hierarchy, and allowssearching across the entire repository of data.

WinFS store can actually be a relational store, where applications canstore their structured as well as unstructured data. Based on themetadata, type of data, and also the relationships of the data withother data as can be specified by the application or the user, WinFSwill assign a relational structure to the data. By using therelationships, WinFS can aggregate related data. WinFS provides aunified storage but stops short of defining the format that is to bestored in the data stores. Instead, it supports data to be written inapplication specific formats. But applications have to provide a schemathat defines how the data should be interpreted. For example, a schemacould be added to allow WinFS to understand how to read and thus be ableto search and analyze, say, a contact. By using the schema, anyapplication can read data from any other application, and also allowsdifferent applications to write in each other's format by sharing theschema.

Multiple WinFS stores can be created on a single machine. This allowsdifferent classes of data to be kept segregated. For example, officialdocuments and personal documents can be kept in different stores. WinFS,by default, provides only one store, named “DefaultStore.” WinFS storesare exposed as shell objects, akin to virtual folders, which dynamicallygenerates a list of all items present in the store and presents them ina folder view. The shell object also allows for the searching ofinformation in the datastore.

WinFS does not have to be a physical file system. Rather, it can providerich data modeling capabilities on top of the NTFS file system. It canuse NTFS to store its data in physical files. WinFS can also use arelational engine, which may be derived from Microsoft® SQL Server 2005,for example, in order to provide a data relations mechanism, since therelation system in WinFS is similar to the relation system used inrelational databases. WinFS stores can be SQL Server database (.MDF)files with a FILESTREAM attribute set. These files can be stored in asecured folder named “System Volume Information” placed into the volumeroot, and in folders under the folder “WinFS” with names of GUIDs ofthese stores.

WinFS also can allow programmatic access to its features, for example,via a set of Microsoft® NET (.NET) application programming interfaces(APIs), that enables applications to define custom made data types,define relationships among data, store and retrieve information, allowadvanced searches, and so on. The applications can then use novel waysof aggregating data and presenting the aggregated data to the user.

Data Storage

A data unit that is stored in a WinFS store is called a WinFS item. AWinFS item also contains information on how the data item is relatedwith other data. A WinFS Item can further consist of sub-entities calledFragments. WinFS allows Items and Fragments to be related together indifferent ways. The different types of relationships are:

-   -   Containment: Containment is an owning relationship. In an owning        relationship there is a parent entity and an child entity    -   Item References: ItemReference is a Fragment type that defines a        relationship that contains data between two item instances based        on the items keys (ItemId). The ItemReference is directed—one        item is the source of the ItemReference and the other item is        the target.    -   Condition based association: Condition based association enable        declaration of relationships between items that are based on a        value of a condition. The condition is an expression that uses        values of the properties of the related items types

WinFS helps in unification of data and thus it reduces redundancies. Ifdifferent applications store data in a non interoperable way, data hasto be duplicated across applications which deal with same data. Forexample, if more than one e-mail application is used, the list ofcontacts must be duplicated across the two. So, when there is any needfor updating contact information, it must be done at two places. If, bymistake, it is not updated in one of the applications, it will continueto have outdated information. But with WinFS, an application can storeall the contact information in a WinFS store, and supply the schema inwhich it is stored. Then, other applications can use the stored data. Bydoing so, duplicate data is removed, and with it the hassles of manuallymaintaining siloed data.

Data Model

WinFS models data using the data items, along with its relationships,fragments and rules governing its usage. WinFS needs to understand thetype and structure of the data items, so that the information stored inthe data item can be made available to any application that requests it.This is done by the use of schemas. For every type of data item that isto be stored in WinFS, a corresponding schema needs to be provided whichwill define the type, structure and associations of the data. Theseschemas are defined, for example, using Extensible Markup Language(XML). XML allows designers to create their own customized tags,enabling the definition, transmission, validation, and interpretation ofdata between applications and between organizations.

Predefined WinFS schemas include schemas for messages, contacts,calendars, file items, etc., and also includes system schemas thatinclude configuration, programs, and other system-related data. Customschemas can be defined on a per-application basis, in situations wherean application wants to store its data in WinFS, but not share thestructure of that data with other applications. Or, they can be madeavailable across the system.

System Types

One key difference between WinFS and other file systems is that WinFSknows the type of each data item that it stores (where the typespecifies the properties of the data item). The WinFS type system can beclosely associated with the NET Framework's concept of classes andinheritance. A new type can be created by extending and nesting anypredefined types.

For example, FIG. 1 shows a block diagram illustrating an exemplary typehierarchy. Shown is item 100 that has three other item types derivingfrom it: contact 102, document 104, and picture 307. Item 100 can be atype that serves as a base class for other items, namely, contact 102type, which may contain various contact information (name, address,etc.); document 104 type that may contain various documentationinformation; and, picture 106 type which may have various digitalimages. The three aforementioned types 102, 104, and 106 may have aspecified relationship 108, 110, 112 to the item type 100 (for instance,some inheritance relationship).

In particular, WinFS provides four predefined base types: Items,Relationships, ScalarTypes, and ComplexTypes (sometimes referred to as“NestedTypes”). An Item is the fundamental data object, which can bestored, and a Relationship is the relation or link between two dataitems. Generally, since all WinFS items should have a type, the type ofitem stored defines its properties. The properties of an Item may be aScalarType, which defines the smallest unit of information a propertycan have, or a ComplexType, which is a collection of more than oneScalarTypes and/or ComplexTypes. All WinFS types are made available asNET Common Language Runtime (CLR) classes. CLR is the core runtimeengine in the Microsoft® .NET Framework for executing applications.

Any object represented as a data unit, such as contact, picture,document, etc, can be stored in a WinFS store as a specialization of theItem type. By default, WinFS provides Item types for Files, Contacts,Documents, Pictures, Audio, Video, Calendar, and Messages. The File Itemcan store any generic data, which is stored in file systems as files.The file item may not be specialized/derived from, but a WinFS schemacan be provided to extend it using fragments that are added on toparticular instances of File items. A file Item can also support beingrelated to other Items. A developer can extend any of the WinFS types(other than File item), or the base type Item, to provide a type for hisor her custom data.

Referring next to FIG. 2, shown is a block diagram illustrating anexample use of the predefined types in defining a new type. The datacontained in an Item is defined in terms of properties, or fields whichhold the actual data. For example, an Item Contact 200 may have a fieldName 202 which is a ScalarType, and one field Address 204, a ComplexType(or “NestedType”), which is further composed of two ScalarTypes: Street206 and City 208. To define this type, the base class Item is extendedand the necessary fields are added to the class. A ComplexType field canbe defined as another class which contains the two ScalarType fields.Once the type is defined, a schema is defined, which denotes theprimitive type of each field. For example, the Name field 202 can be astring, the Address field 204 is a custom defined Address class. And,both of the ScalarTypes 206, 208 can be strings. Furthermore, otherprimitive types that WinFS supports are Integer, Byte, Decimal, Float,Double, Boolean and DateTime, and so on. The schema will also definewhich fields are mandatory and which are optional. The Contact Item 401defined in this way will be used to store information regarding theContact, by populating the properties field and storing it. If moreproperties on the item need to be added, such as “last conversed date,”this type can be simply extended to accommodate them. Item types forother data can be defined similarly.

Referring next to FIG. 3, shown is a block diagram illustrating anexemplary relation stored as a reference to a particular row in thetable of an item. WinFS creates a table 300 for all defined Items 302,304. All the fields defined for the Picture Item 302 form the columns306 of the table 300; and all instances of the Picture Item 302 arestored as rows 308 in the table 300 for the respective Item 302. ARelation 310 is stored as a reference to the particular row 312 in thetable of the Contact Item 304, which holds the instance of the targetItem 304 with which the current Item 302 is related. All Items 302, 304can be exposed as NET CLR objects, with uniform interface providingaccess to the data stored in the fields. Thus, any application canretrieve object of any Item type and can use the data in the object,without worrying about the physical structure the data was stored in.

Synchronization of Entity Stores

As a matter of nomenclature, so far, the present disclosure has referredto “items” in item stores. However, more broadly speaking, entities canbe either items or fragments, where items can exist independently andfragments typically exist within a context of an item. Those of skill inthe art will readily appreciate that entities are schematized types(i.e. object types), of which items are independent types. In thepresent disclosure, at times, “items” and “entities” are usedinterchangeably, depending on the context. Moreover, those of skill inthe art will also readily appreciate that different stores may containdifferent types of entities (either within such stores or across stores,where one entity store has entities of a first type and another storehas entities of a second type).

FIG. 4, illustrates a basic synchronization scenario including an aspectof the presently disclosed subject matter. A synchronization adapter 412(i.e. a “module”) synchronizes a local entity store 400 and a remoteentity store 402. Each of these stores may have some entities (items andfragments). For example, the local store 400 has an item A 404 and anitem B 406, and these items may be tagged with identification marks (forexample, GUIDs or other identifiers). Such identification of itemsacross stores can be maintained in an identification map (such as atable), however such identification is not limited to a table. Forexample, a generic mapping mechanism 420 is shown, where a local store400 identification for Item A 404 is “A” and the corresponding remotestore 402 identification for Item A′ 408 is “A′”. Similarly, Item B 406is related to Item B′ 410 because of the B to B′ identificationcorrespondence in the mapping mechanism 420.

When the synchronization adapter 412 synchronizes the two stores 400,402, it performs some synchronization operation 414. Along with thisoperation 414, the synchronization adapter 412 can also provide anyidentification information 416 (such as the information maintained bythe mapping mechanism 420). Synchronizing data and identificationinformation at the same time allows for dynamic maintenance of identityrelationships. Similarly, providing identification information pursuantto synchronizing data, such as with an acknowledgement operation, canalso aid in mapping identification information. Such simultaneousoperation and identifier handling ensures data consistency. Andmoreover, to further ensure such consistency, any synchronizationapplication programming interfaces (APIs) may be integrated with anyidentifier mapping APIs.

Furthermore, metadata information 410 can be maintained alongside (orwithin) the mapping mechanism 420. Such metadata, which may beunderstood as secondary storage in relation to the identificationstorage of the mapping mechanism 420, may be useful for storage of datasuch as watermark data (e.g. when data was synchronized the last time orsome other indicator of version), secondary remote identificationinformation, and so on.

In one aspect of the presently disclosed subject matter, thesynchronization operations 414, the identification information 416, andthe metadata information 418, is part of the same synchronizationoperation. This is a very useful feature in numerous scenarios. Forexample, in a system that does not provide such atomicity of operations414 and information 416, 418, if an operation is performed first, andthen the system crashes, without having had the opportunity to updateits mapping tables, then the state of its data will be inconsistent.Such systems that maintain separate synchronization operations fromidentification maintenance (or at least perform these two tasks atdifferent times as two separate transactions), suffer from a host ofsuch problems.

In contrast, because the presently disclosed subject matter transactsoperations 414 along with information 416, 418 related to identitymapping, this problem is obviated and any data stored in the entitystores 400, 402 is kept consistent. Furthermore, this feature isespecially useful if the presently disclosed subject matter is embodiedas a programming platform, essentially maintaining mapping information(in the mapping mechanism 420) along with any synchronization operations(add data, deleted data, update data, etc.). In short, the presentlydisclosed subject matter performs in the same transaction asynchronization operation along with an entity identification operationand a metadata operation. In one aspect, if a synchronization operationis performed, the entity identification operations and/or metadataoperation are performed automatically for a user or developer so thatsuch an individual does not have to separately perform or address saidlatter operation. In another aspect, such automatic coupling ofoperations can be accomplished via an application programming interface(API) where if an individual (or another module, for that matter)selects a synchronization operation, the entity identification operationand/or metadata operations are done behind the scenes—so that the API inessence serves as an API for synchronization and for mapping maintenanceand/or metadata maintenance.

FIG. 5 illustrates the potential disparity between identificationinformation hierarchy and entity hierarchy. In FIG. 5, a synchronizationsystem employing aspect of the presently disclosed subject matter canhandle such a disparity, which may be especially advantageous when thestructure of the identification hierarchy is amenable to query requests.Thus, IdA 500 may be a root identifier and have children identifiers,namely Id B 502, Id C 504, Id D 506, Id E 508, and Id F 710. Thisstructure may differ from the entity hierarchy, as can be seen: Entity A501 has a child Entity B 503, but this entity 503 has a child entity F511 (whereas, Id B 502 has a child identifier Id C 504.

Next, FIG. 6, illustrates that identifiers may be assigned to individualcomponents of a given entity. For example, given entity 620, the firstcomponent 622 may have assigned Id A 500; the second component 624 mayhave assigned Id B 502; and the third component 626 may have assigned IdC 504. Any given entity can have a plurality of components and hence aplurality of corresponding identifiers.

FIG. 7, illustrates that a merger of entities may result in assignmentof primary and secondary identifiers. Thus, entity A 730 has identifierId A 500; and, entity B 732 has identifier Id B 502. One of two thingscan happen at this point—either [1] entity A 730 or [2] entity B 732 isthe “winning” entity which is assigned the primary identifier (the“losing” entity can be assigned a secondary identifier). In FIG. 7, themerged entity 734 has Id A 500 as the primary Id 736 and Id B 502 as thesecondary Id 738. This means that upon merger, entity A 730 was thewinning entity (a fact that could be acknowledged by the synchronizationadapter. Moreover, any identification mechanism discussed above can keeptrack of such a merger and assign the mentioned identifiers accordingly.

FIG. 8, illustrates the fact that a secondary (per entity) storage maybe provided with each entity. Such storage may contain some metadatafurther supplementing identifying information relationships, as wasdiscussed above. Such metadata could refer to watermark data, secondaryidentification data, etc. Thus, entity A 730, with an ID A 500, hassecondary storage for metadata 800.

Those skilled in the art will readily appreciate the numerous scenariosthat could unfold in the context of the presently disclosed subjectmatter, so there is no need to state them here. However, the followingare some of the more interesting scenarios: scenario 1, anidentification map can be automatically maintained for deletes appliedduring application of remote changes to a local store (such as WinFS),even if the previously supplied identification is not supplied for thecurrent operation. Scenario 2: an identification map can be maintainedfor local store side deletes acknowledged as applied remotely. Scenario3: an identification map can be automatically maintained on processingresurrections (see below for more) for update or delete constraintconflicts. These are only but three exemplary and non-limitingscenarios.

In summary, FIG. 8 illustrates in block diagram form the aspect of thepresently disclosed subject matter. At block 800, pursuant to asynchronization operation, a use or access is made to a first entitystore. Then, at block 802, the same use or access is made for a secondentity store. Now, at block 804, these two stores can be synchronizedwith a synchronization operation providing along also identification andmetadata information for entities. Once this is done, at block 806,acknowledgement of synchronization can be provided (possibly providingalso identification information and metadata information).

Exemplary Implementation of an Identification Facility

Various code samples for a mapping facility can be constructed. Thefollowing is an exemplary coding of the aspects discussed above for areceive synchronization (this is the case where a synchronizing systemis receiving and data is being sent from the remote store):

[Optionally start a transaction] StorageContext ctx = new StorageContext(...) // Acquire a sync service SyncService SyncService =  (SyncService)ctx.GetService(typeof(SyncService)); SyncService.Initialize(replicaItemId, remotePartnerId ); // Get the remote knowledgeReplicaKnowledge remoteKnowledge = Foo.RetrieveRemoteKnowledge( );foreach (batch of changes) {  foreach (changed RemoteEntity in batch) //Iterate over the changes from the remote store  {   // Lookup the remoteentity using the id mapping facility   StorageKey sk =syncService.GetLocalKeyForRemoteId(remoteEntity.Id);   Entity e;   if(sk != null)    e = ctx.GetObjectByKey(sk) as Entity;   if (sk != null&&e != null) // The item exists in the map and in WinFS   {    // Updatethe item with the remote data    e.foo = remoteEntity.foo;    e.bar =remoteEntity.bar;    // Record the Id   e.SyncHelper.SetRemoteId(remoteEntity.Id);   }   else   {    if (sk!= null) // No local item, but in id map so update/delete conflict    {    // Adapter chooses whether to delete wins, or instead to do a create   }    else    {     // This is a new entity     // Create the entity    e = CreateFooFromRemoteRemoteEntity(remoteEntity.Data);     //Populate the properties of the entity as appropriate     // Record thenew id mapping     e.SyncHelper.SetRemoteId(remoteEntity.Id);    }   } }  remoteKnowledge = syncService.SaveContextChanges(remoteKnowledge); }// Store the remote knowledge Foo.StoreRemoteKnowledge(remoteKnowledge);// Finish with the context ctx.SaveChanges( ); ctx.Close( ); [Iftransaction was opened, it will be commited]

In contrast to the code shown above, the following is sample code for asend synchronization (this is the case where a synchronization system issending and the remote store is receiving synchronizing operations(optionally, also with identification and metadata information):

StorageContext ctx = new StorageContext (...) // Acquire a sync servicesSyncService syncService =    (sSyncService)ctx.GetService(typeof(sSyncService)); sSyncService.Initialize(replicaItemId, remotePartnerId ); // Get the remote knowledgeReplicaKnowledge remoteKnowledge = Foo.RetrieveRemoteKnowledge( ); //Acquire a ChangeReader using ( ChangeReader reader =sSyncService.GetChangeReader( remoteKnowledge ) ) {  // Enumerate andprocess changes  foreach (CompoundItemChange cic in reader)  {   //Process the root item   ItemChange ic = cic.RootItemChange;   // Is thisa create, a delete, or an update   try   {    switch (ic.ChangeType)   {     case ChangeType.Create:      // Create a remote record     Foo.AddRemoteEntity(ic.Data);      // Record the mapping     ic.RemoteMetadata.RemoteId = MyRemoteId;     caseChangeType.Update:      // Update the corresponding remote record     Foo.UpdateRemoteEntity(ic.RemoteMetadata.RemoteId, ic.Data);    case ChangeType.Delete:     Foo.DeleteRemoteEntity(ic.RemoteMetadata.RemoteId);    }   reader.AcknowledgeChange(ic, ChangeResult.Success);   }  catch(MyRemoteStoreException ex)   {    . . .    // Error happenedapplying to the remote store    // For example purposes we assume theerror is recoverable    // report error to the ChangeReader and move on   reader.AcknowledgeChange(ic, ChangeResult.Error);   }    // First,links    // Analogous processing to item    // Next, fragments    //Analogous to links.    . . .    // Next, extensions   foreach(ItemExtensionChange iec in ic.ExtensionChanges)    {     //Processing the ItemExtensionChange is analogous to other *Change //However, setting iec.RemoteId is optional as Extension lifetime isn'tmanaged for     // via id facility lookup. Instead lifetime iscoincident with corresponding Item lifetime.     [iec.RemoteId = ...;]    // Acknowledge the change     reader.AcknowledgeChange(lc,ChangeResult.Success);    }    // Then process embedded items    . . .  }   Foo.StoreRemoteKnowledge(ChangeReader.GetUpdatedRemoteKnowledge());   reader.Close( ); } // Finish with the context ctx.SaveChanges( );ctx.Close( );

A mapping facility can be exposed on a synchronization service(SyncService) class. It can be available to all users of thesynchronization functionality. In the sample code below, eachidentification mapping table is per (replicaId, remotePartnerID) pair:

Namespace System.Storage.Sync {  public class SyncService  {   // Classis otherwise unchanged - these are all additions   // Keep all existingmembers   public void  Initialize (Guid replicaId, Guid remotePartnerId);   // Id mapping facility lookup methods   public StorageKeyGetLocalKeyForRemoteId(string remoteId);   public string  GetRemoteIdForLocalKey(StorageKey localKey);   public RemoteMetadataGetRemoteMetadataForLocalKey(StorageKey  localKey);   publicRemoteMetadata GetRemoteMetadataForRemoteId(string remoteId);   publicRemoteMetadata GetRemoteMetadataForRemoteId(string remoteId,   outStorageKey localKey)   public IEnumerable<KeyValuePair<StorageKey,RemoteMetadata>>  GetChildRemoteMetadataForParentRemoteId(stringremoteId);   public void BatchSaveRemoteMetadataUpdates(IList<KeyValuePair<StorageKey,RemoteMetadata>>);   // Adapter metadata storage   public InlineType LoadRemotePartnerData( );    public voidSaveRemotePartnerData(InlineType remotePartnerData);  } }

The identification mapping facility can be provided for use withsynchronization. The result is that it frees adapter writers from havingto maintain their own identification maps. Moreover, also provided isthe ability to optionally store adapter specific per-entity metadataalong with the mapping. Specifically, the storage of any InlineType canbe provided. Adapter writers can either use an exisiting InlineType ordefine their own custom InlineType (via the usual system schemadefinition mechanisms) to store their custom metadata. The latter optionis more complicated than the former, but offers greater flexibility.

The benefits of using the identification mapping service include: (1)Allowance of attaching a remote parent identification as well as aremote identification to an item—this allows one to model the remotehierarchy in the identification map; the ability to do lookups in the idmap by this hierarchy is provided; (2) The identification mappingservice is integrated with the synchronization APIs thus making iteasier to access and update the id map; (3) The id mapping servicehandles map maintenance under some specific sync operations,specifically processing of deletes, merge conflict resolution, etc.

This is but an exemplary coding of some of the aspects discussed above.Those skilled in the art will readily appreciate how to code theremaining aspects discussed above.

Sample Identification Mapping Information

In order to keep track of items, identification mapping information canbe stored in a table (or some other such mapping mechanism, per thediscussion above). For example, for identification mapping maintenanceduring update or delete conflicts, the following table may be accessedby the mentioned synchronization adapter:

ReplicaId RemotePartnerId LocalId RemoteId ReplicaId1 RemotePartnerId1Lid1 Rid1

The initial state is that a local store and a remote store have itemwith local Id Lid1 and remote id Rid1, respectively. For a resurrectioncase (where an item is “resurrected” or brought back into existence,after perhaps, having been deleted), when item in the remote store isupdated, a local synchronization adapter detects that item in localstore is not in the synchronization scope (either because it was removedfrom the scope or deleted from the system altogether), therefore it willresurrect that item. Resurrected item will have the same remote id Rid1and different local Id=Lid2.

When an item is successfully resurrected (assuming conflict policy was“remote update wins”), existing identification mapping information alongwith remote metadata needs to be reassigned to the new Lid2 of theresurrected item:

ReplicaId RemotePartnerId LocalId RemoteId ReplicaId1 RemotePartnerId1Lid2 Rid1

When an item is deleted (assuming conflict policy was “local deletewins”), existing identification mapping information needs to be deleted.This will happen when synchronization will be done from the local storeto the remote store, and the synchronization will enumerate deletechanges for the item. Upon acknowledgement of that change, theidentification mapping information will be deleted from the store.

Another sample mapping involves identification maintenance during mergeconflicts (briefly discussed in the context of entities in FIG. 7). Forexample, the initial state for the local store can be: F1→I1; and F2→I2.The remote store can have: F2→I2. The table mapping entries, then, wouldbe:

ReplicaId RemotePartnerId LocalId RemoteId ReplicaId1 RemotePartnerId1Lid(F2) Rid(F2) ReplicaId1 RemotePartnerId1 Lid(I2) Rid(I2)

Now, another local store replica can cause F2 to be renamed to F1 andthis change gets applied to the local store replica causing merge tohappen. Thus, now the state in the local store would be: F1→I1 and I2;and F2 ceases to exist (it is said to be a “tombstone”). Such a“tombstone” may not have any data, but it may still contain metadatathat may be useful in synchronization—especially if multiple stores areinvolved in synchronization.

Now changes can be enumerated from the local store and applied to theremote store. The following changes get enumerated:

-   -   1. Merge create for F1 with secondary remote metadata for F2        (merge loser).    -   2. Create for I1.    -   3. Create for I2.    -   4. Merge delete for F2.

In this case, identification mapping change enumeration code will checkif secondary remote metadata (for the merge loser) on the merge winnerchange has the same remote identification as the merge winner remotemetadata (possibly assigned by adapter to be the same as of merge loserto reuse the same remote store item e.g. like directory in a filesystem), and if yes, then secondary remote metadata gets transferred tothe merge winner to prevent it from being deleted when delete change forthe merge loser gets acknowledged.

Exemplary Computing and Networking Environment

Referring to FIG. 10, shown is a block diagram representing an exemplarycomputing device suitable for use in conjunction with implementing thesystems and methods described above. For example, the computerexecutable instructions that carry out the processes and methods foridentification of entities with synchronization operations may resideand/or be executed in such a computing environment as shown in FIG. 10.The computing system environment 220 is only one example of a suitablecomputing environment and is not intended to suggest any limitation asto the scope of use or functionality of the presently disclosed subjectmatter. Neither should the computing environment 220 be interpreted ashaving any dependency or requirement relating to any one or combinationof components illustrated in the exemplary operating environment 220.For example a computer game console may also include those items such asthose described below for use in conjunction with implementing theprocesses described above.

Aspects of the presently disclosed subject matter are operational withnumerous other general purpose or special purpose computing systemenvironments or configurations. Examples of well known computingsystems, environments, and/or configurations that may be suitable foruse with the this subject matter include, but are not limited to,personal computers, server computers, hand-held or laptop devices,multiprocessor systems, microprocessor-based systems, set top boxes,programmable consumer electronics, network PCs, minicomputers, mainframecomputers, distributed computing environments that include any of theabove systems or devices, and the like.

Aspects of the presently disclosed subject matter may be implemented inthe general context of computer-executable instructions, such as programmodules, being executed by a computer. Generally, program modulesinclude routines, programs, objects, components, data structures, etc.that perform particular tasks or implement particular abstract datatypes. Aspects of the presently disclosed subject matter may also bepracticed in distributed computing environments where tasks areperformed by remote processing devices that are linked through acommunications network. In a distributed computing environment, programmodules may be located in both local and remote computer storage mediaincluding memory storage devices.

An exemplary system for implementing aspects of the presently disclosedsubject matter includes a general purpose computing device in the formof a computer 241. Components of computer 241 may include, but are notlimited to, a processing unit 259, a system memory 222, and a system bus221 that couples various system components including the system memoryto the processing unit 259. The system bus 221 may be any of severaltypes of bus structures including a memory bus or memory controller, aperipheral bus, and a local bus using any of a variety of busarchitectures. By way of example, and not limitation, such architecturesinclude Industry Standard Architecture (ISA) bus, Micro ChannelArchitecture (MCA) bus, Enhanced ISA (EISA) bus, Video ElectronicsStandards Association (VESA) local bus, and Peripheral ComponentInterconnect (PCI) bus also known as Mezzanine bus.

Computer 241 typically includes a variety of computer readable media.Computer readable media can be any available media that can be accessedby computer 241 and includes both volatile and nonvolatile media,removable and non-removable media. By way of example, and notlimitation, computer readable media may comprise computer storage mediaand communication media. Computer storage media includes both volatileand nonvolatile, removable and non-removable media implemented in anymethod or technology for storage of information such as computerreadable instructions, data structures, program modules or other data.Computer storage media includes, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD) or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can accessed by computer 241. Communication media typicallyembodies computer readable instructions, data structures, programmodules or other data in a modulated data signal such as a carrier waveor other transport mechanism and includes any information deliverymedia. The term “modulated data signal” means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. Combinations of the any of the aboveshould also be included within the scope of computer readable media.

The system memory 222 includes computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 223and random access memory (RAM) 260. A basic input/output system 224(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 241, such as during start-up, istypically stored in ROM 223. RAM 260 typically contains data and/orprogram modules that are immediately accessible to and/or presentlybeing operated on by processing unit 259. By way of example, and notlimitation, FIG. 10 illustrates operating system 225, applicationprograms 226, other program modules 227, and program data 228.

The computer 241 may also include other removable/non-removable,volatile/nonvolatile computer storage media. By way of example only,FIG. 10 illustrates a hard disk drive 238 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 239that reads from or writes to a removable, nonvolatile magnetic disk 254,and an optical disk drive 240 that reads from or writes to a removable,nonvolatile optical disk 253 such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the exemplary operating environment include,but are not limited to, magnetic tape cassettes, flash memory cards,digital versatile disks, digital video tape, solid state RAM, solidstate ROM, and the like. The hard disk drive 238 is typically connectedto the system bus 221 through an non-removable memory interface such asinterface 234, and magnetic disk drive 239 and optical disk drive 240are typically connected to the system bus 221 by a removable memoryinterface, such as interface 235.

The drives and their associated computer storage media discussed aboveand illustrated in FIG. 10, provide storage of computer readableinstructions, data structures, program modules and other data for thecomputer 241. In FIG. 10, for example, hard disk drive 238 isillustrated as storing operating system 258, application programs 257,other program modules 256, and program data 255. Note that thesecomponents can either be the same as or different from operating system225, application programs 226, other program modules 227, and programdata 228. Operating system 258, application programs 257, other programmodules 256, and program data 255 are given different numbers here toillustrate that, at a minimum, they are different copies. A user mayenter commands and information into the computer 241 through inputdevices such as a keyboard 251 and pointing device 252, commonlyreferred to as a mouse, trackball or touch pad. Other input devices (notshown) may include a microphone, joystick, game pad, satellite dish,scanner, or the like. These and other input devices are often connectedto the processing unit 259 through a user input interface 236 that iscoupled to the system bus, but may be connected by other interface andbus structures, such as a parallel port, game port or a universal serialbus (USB). A monitor 242 or other type of display device is alsoconnected to the system bus 221 via an interface, such as a videointerface 232. In addition to the monitor, computers may also includeother peripheral output devices such as speakers 244 and printer 243,which may be connected through a output peripheral interface 233.

The computer 241 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer246. The remote computer 246 may be a personal computer, a server, arouter, a network PC, a peer device or other common network node, andtypically includes many or all of the elements described above relativeto the computer 241, although only a memory storage device 247 has beenillustrated in FIG. 10. The logical connections depicted in FIG. 10include a local area network (LAN) 245 and a wide area network (WAN)249, but may also include other networks. Such networking environmentsare commonplace in offices, enterprise-wide computer networks, intranetsand the Internet.

When used in a LAN networking environment, the computer 241 is connectedto the LAN 245 through a network interface or adapter 237. When used ina WAN networking environment, the computer 241 typically includes amodem 250 or other means for establishing communications over the WAN249, such as the Internet. The modem 250, which may be internal orexternal, may be connected to the system bus 221 via the user inputinterface 236, or other appropriate mechanism. In a networkedenvironment, program modules depicted relative to the computer 241, orportions thereof, may be stored in the remote memory storage device. Byway of example, and not limitation, FIG. 10 illustrates remoteapplication programs 248 as residing on memory device 247. It will beappreciated that the network connections shown are exemplary and othermeans of establishing a communications link between the computers may beused.

It should be understood that the various techniques described herein maybe implemented in connection with hardware or software or, whereappropriate, with a combination of both. Thus, the methods and apparatusof the presently disclosed subject matter, or certain aspects orportions thereof, may take the form of program code (i.e., instructions)embodied in tangible media, such as floppy diskettes, CD-ROMs, harddrives, or any other machine-readable storage medium wherein, when theprogram code is loaded into and executed by a machine, such as acomputer, the machine becomes an apparatus for practicing the presentlydisclosed subject matter. In the case of program code execution onprogrammable computers, the computing device generally includes aprocessor, a storage medium readable by the processor (includingvolatile and non-volatile memory and/or storage elements), at least oneinput device, and at least one output device. One or more programs thatmay implement or utilize the processes described in connection with thepresently disclosed subject matter, e.g., through the use of an API,reusable controls, or the like. Such programs are preferably implementedin a high level procedural or object oriented programming language tocommunicate with a computer system. However, the program(s) can beimplemented in assembly or machine language, if desired. In any case,the language may be a compiled or interpreted language, and combinedwith hardware implementations.

Although exemplary embodiments may refer to utilizing aspects of thepresently disclosed subject matter in the context of one or morestand-alone computer systems, the said subject matter is not so limited,but rather may be implemented in connection with any computingenvironment, such as a network or distributed computing environment.Still further, aspects of the presently disclosed subject matter may beimplemented in or across a plurality of processing chips or devices, andstorage may similarly be effected across a plurality of devices. Suchdevices might include personal computers, network servers, handhelddevices, supercomputers, or computers integrated into other systems suchas automobiles and airplanes.

In light of the diverse computing environments that may be builtaccording to the general framework provided in FIG. 10, the systems andmethods provided herein cannot be construed as limited in any way to aparticular computing architecture. Instead, the presently disclosedsubject matter should not be limited to any single embodiment, butrather should be construed in breadth and scope in accordance with theappended claims.

Referring next to FIG. 11, shown is an exemplary networked computingenvironment in which many computerized processes may be implemented toperform the processes described above. For example, parallel computingmay be part of such a networked environment with various clients on thenetwork of FIG. 11 using and/or implementing the defining and extractingof a flat list of search properties from a rich structured type. One ofordinary skill in the art can appreciate that networks can connect anycomputer or other client or server device, or in a distributed computingenvironment. In this regard, any computer system or environment havingany number of processing, memory, or storage units, and any number ofapplications and processes occurring simultaneously is consideredsuitable for use in connection with the systems and methods provided.

Distributed computing provides sharing of computer resources andservices by exchange between computing devices and systems. Theseresources and services include the exchange of information, cachestorage and disk storage for files. Distributed computing takesadvantage of network connectivity, allowing clients to leverage theircollective power to benefit the entire enterprise. In this regard, avariety of devices may have applications, objects or resources that mayimplicate the processes described herein.

FIG. 11 provides a schematic diagram of an exemplary networked ordistributed computing environment. The environment comprises computingdevices 271, 272, 276, and 277 as well as objects 273, 274, and 275, anddatabase 278. Each of these entities 271, 272, 273, 274, 275, 276, 277and 278 may comprise or make use of programs, methods, data stores,programmable logic, etc. The entities 271, 272, 273, 274, 275, 276, 277and 278 may span portions of the same or different devices such as PDAs,audio/video devices, MP3 players, personal computers, etc. Each entity271, 272, 273, 274, 275, 276, 277 and 278 can communicate with anotherentity 271, 272, 273, 274, 275, 276, 277 and 278 by way of thecommunications network 270. In this regard, any entity may beresponsible for the maintenance and updating of a database 278 or otherstorage element.

This network 270 may itself comprise other computing entities thatprovide services to the system of FIG. 11, and may itself representmultiple interconnected networks. In accordance with an aspect of thepresently disclosed subject matter, each entity 271, 272, 273, 274, 275,276, 277 and 278 may contain discrete functional program modules thatmight make use of an API, or other object, software, firmware and/orhardware, to request services of one or more of the other entities 271,272, 273, 274, 275, 276, 277 and 278.

It can also be appreciated that an object, such as 275, may be hosted onanother computing device 276. Thus, although the physical environmentdepicted may show the connected devices as computers, such illustrationis merely exemplary and the physical environment may alternatively bedepicted or described comprising various digital devices such as PDAs,televisions, MP3 players, etc., software objects such as interfaces, COMobjects and the like.

There are a variety of systems, components, and network configurationsthat support distributed computing environments. For example, computingsystems may be connected together by wired or wireless systems, by localnetworks or widely distributed networks. Currently, many networks arecoupled to the Internet, which provides an infrastructure for widelydistributed computing and encompasses many different networks. Any suchinfrastructures, whether coupled to the Internet or not, may be used inconjunction with the systems and methods provided.

A network infrastructure may enable a host of network topologies such asclient/server, peer-to-peer, or hybrid architectures. The “client” is amember of a class or group that uses the services of another class orgroup to which it is not related. In computing, a client is a process,i.e., roughly a set of instructions or tasks, that requests a serviceprovided by another program. The client process utilizes the requestedservice without having to “know” any working details about the otherprogram or the service itself. In a client/server architecture,particularly a networked system, a client is usually a computer thataccesses shared network resources provided by another computer, e.g., aserver. In the example of FIG. 11, any entity 271, 272, 273, 274, 275,276, 277 and 278 can be considered a client, a server, or both,depending on the circumstances.

A server is typically, though not necessarily, a remote computer systemaccessible over a remote or local network, such as the Internet. Theclient process may be active in a first computer system, and the serverprocess may be active in a second computer system, communicating withone another over a communications medium, thus providing distributedfunctionality and allowing multiple clients to take advantage of theinformation-gathering capabilities of the server. Any software objectsmay be distributed across multiple computing devices or objects.

Client(s) and server(s) communicate with one another utilizing thefunctionality provided by protocol layer(s). For example, HyperTextTransfer Protocol (HTTP) is a common protocol that is used inconjunction with the World Wide Web (WWW), or “the Web.” Typically, acomputer network address such as an Internet Protocol (IP) address orother reference such as a Universal Resource Locator (URL) can be usedto identify the server or client computers to each other. The networkaddress can be referred to as a URL address. Communication can beprovided over a communications medium, e.g., client(s) and server(s) maybe coupled to one another via TCP/IP connection(s) for high-capacitycommunication.

In light of the diverse computing environments that may be builtaccording to the general framework provided in FIG. 11 and the furtherdiversification that can occur in computing in a network environmentsuch as that of FIG. 11, the systems and methods provided herein cannotbe construed as limited in any way to a particular computingarchitecture or operating system. Instead, the presently disclosedsubject matter should not be limited to any single embodiment, butrather should be construed in breadth and scope in accordance with theappended claims.

Lastly, while the present disclosure has been described in connectionwith the preferred aspects, as illustrated in the various figures, it isunderstood that other similar aspects may be used or modifications andadditions may be made to the described aspects for performing the samefunction of the present disclosure without deviating therefrom. Forexample, in various aspects of the disclosure, mechanisms foridentification of entities with synchronization operations as disclosed.However, other equivalent mechanisms to these described aspects are alsocontemplated by the teachings herein. Therefore, the present disclosureshould not be limited to any single aspect, but rather construed inbreadth and scope in accordance with the appended claims.

1. A system for synchronizing entity stores, comprising: a local entitystore configured to maintain at least one local entity of a first type;a remote entity store configured to maintain at least one remote entityof a second type different from the first type; and a module forsynchronizing entities, wherein said module synchronizes one of (a) saidat least one local entity of said first type with said at least oneremote entity of said second type and (b) said at least one remoteentity of said second type with said at least one local entity of saidfirst type, by performing an atomic transaction comprising asynchronization operation, an entity identity operation to automaticallyupdate entity identity relationships based on the synchronizationoperation, and a metadata operation to automatically update metadatastored in association with one or more entities based on thesynchronization operation.
 2. The system according to claim 1, whereinsaid module persists in a programming platform and is accessible via asynchronization application programming interface.
 3. The systemaccording to claim 1, wherein said synchronization operation merges afirst entity, including one of said at least one local entity and atleast one remote entity, with a second entity to generate a mergedentity, and wherein said entity identity operation assigns an identityof the first entity or second entity as a primary identity of the mergedentity.
 4. The system according to claim 1, wherein said synchronizationoperation resurrects a previously deleted entity in one of said localentity store and remote entity store and wherein said identity operationone of (a) assigns a new identity to said previously deleted entity and(b) maintains an original identity for said previously deleted entity.5. The system according to claim 1, wherein said synchronizationoperation deletes one of said at least one local entity and at least oneremote entity, in response said metadata operation maintains metadataassociated with said one of said at least one local entity and at leastone remote entity, respectively.
 6. The system according to claim 1,further comprising an application programming interface that isconfigured for synchronization using said module, wherein said interfaceprovides for selecting said synchronization operation, wherein saidentity identity operation performs maintenance of identity mapping ofentities in said local entity store and said remote entity storepursuant to said selection of said synchronization operation.
 7. Thesystem according to claim 1, further comprising an additional entitystore, wherein one of said local entity store and said remote entitystore is synchronized with said additional entity store.
 8. A method forsynchronizing entity stores, comprising: accessing a local entity storeconfigured to maintain at least one local entity of a first type;accessing a remote entity store configured to maintain at least oneremote entity of a second type different from the first type; andsynchronizing one of (a) said at least one local entity of said firsttype with said at least one remote entity of said second type and (b)said at least one remote entity of said second type with said at leastone local entity of said first type by performing an atomic transactioncomprising a synchronization operation, an entity identity operation toautomatically update entity identity relationships based on thesynchronization operation, and a metadata operation.
 9. The methodaccording to claim 8, further comprising providing access to configuresaid synchronizing via a synchronization application programminginterface associated with a programming platform.
 10. The methodaccording to claim 8, further comprising synchronizing by merging afirst entity, including one of said at least one local entity and atleast one remote entity, with a second entity to create a merged entity,in response said entity identity operation assigning an identity of thefirst entity or second entity as a primary identity of the mergedentity.
 11. The method according to claim 8, further comprisingperforming said synchronization operation that resurrects a previouslydeleted entity in one of said local entity store and remote entity storeand performing said identity operation that one of (a) assigns a newidentity to said previously deleted entity and (b) maintains an originalidentity for said previously deleted entity.
 12. The method according toclaim 8, further comprising synchronizing by deleting one of said atleast one local entity and at least one remote entity, in response saidmetadata operation maintains metadata associated with said one of saidat least one local entity and at least one remote entity, respectively.13. The method according to claim 8, further comprising providing anapplication programming interface that is configured for synchronizationusing a synchronization module, wherein said interface provides forselecting said synchronization operation, wherein said entity identityoperation performs maintenance of identity mapping of entities in saidlocal entity store and said remote entity store pursuant to saidselection of said synchronization operation.
 14. The method according toclaim 8, further comprising synchronizing an additional store with atleast one of said local entity store and said remote store.
 15. Acomputer readable storage medium comprising computer executableinstructions tangibly embodied on the computer readable storage medium,wherein the computer executable instructions are executable by acomputer to perform acts for synchronizing entity stores, wherein theacts comprise: accessing a local entity store configured to maintain atleast one local entity of a first type; accessing a remote entity storeconfigured to maintain at least one remote entity of a second typedifferent from the first type; and synchronizing one of (a) said atleast one local entity of said first type with said at least one remoteentity of said second type and (b) said at least one remote entity ofsaid second type with said at least one local entity of said first typeby performing an atomic transaction comprising a synchronizationoperation, an entity identify operation to automatically update entityidentity relationships based on the synchronization operation, and ametadata operation.
 16. The computer readable storage medium accordingto claim 15, further comprising computer executable instructions thatare executable by a computer to perform an act of providing access toconfigure said synchronizing via a synchronization applicationprogramming interface associated with a programming platform.
 17. Thecomputer readable storage medium according to claim 15, furthercomprising computer executable instructions that are executable by acomputer to perform acts of synchronizing by merging a first entity,including one of said at least one local entity and at least one remoteentity, with a second entity to create a merged entity, in response saidentity identity operation assigning an identity of the first entity orsecond entity as a primary identity of the merged entity.
 18. Thecomputer readable storage medium according to claim 15, furthercomprising computer executable instructions that are executable by acomputer to perform acts of performing said synchronization operationthat resurrects a previously deleted entity in one of said local entitystore and remote entity store and performing said identity operationthat one of (a) assigns a new identity to said previously deleted entityand (b) maintains an original identity for said previously deletedentity.
 19. The computer readable storage medium according to claim 15,further comprising computer executable instructions that are executableby a computer to perform acts of synchronizing by deleting one of saidat least one local entity and at least one remote entity, in responsesaid metadata operation maintains metadata associated with said one ofsaid at least one local entity and at least one remote entity,respectively.
 20. The computer readable storage medium according toclaim 15, further comprising computer executable instructions that areexecutable by a computer to perform acts of providing an applicationprogramming interface that is configured for synchronization using asynchronization module, wherein said interface provides for selectingsaid synchronization operation, wherein said entity identity operationperforms maintenance of identity mapping of entities in said localentity store and said remote entity store pursuant to said selection ofsaid synchronization operation.